FIG. 1 illustrates an interfacing between a workstation 10 operating as a data initiator device and a server 20 operating as a data target device whereby workstation 10 issues read commands directed to transfers of data units responsive to the read commands from server 20 to workstation 10. To this end, workstation 10 has traditionally issued the read commands under a data transfer protocol (“DTP”) 11 having a fixed designation of data tags 12 for tagging the data transfers whereby each data unit can be identified as corresponding to a particular read command. Specifically, a data tag is attached to both a read command by workstation 10 and a responsive data unit by server 20 to thereby facilitate an identification of a correspondence of the responsive data unit to that particular read command.
Data tags 12 historically have been incremented in a looped manner (e.g., 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, . . . ) with an intention of maintaining a sequential command ordering of data by workstation 10. This sequential command ordering involves a receipt by workstation 10 of a data unit responsive to the most current read command issued by workstation 10 prior to an issuance of a new read command by workstation 10. In an absence of any errors in the transfer of data units from server 20 to workstation 10, the looped incrementing of data tags 12 has proven to be efficient in facilitating an identification of a correspondence of each data unit to a particular read command even when the sequential command ordering of data is not maintained by workstation 10. However, in the presence of an error in the transfer of a data unit from server 20 to workstation 10, the looped incrementing of data tags 12 has proven to be ineffective in facilitating an identification of a correspondence of each data unit to a particular read command irrespective of whether the sequential ordering of data is or is not maintained by workstation 10.
For example, as illustrated in FIG. 1, sequential data transfers from server 20 to workstation 10 of data units 1–3 responsive to read commands 1-3, respectively, tagged with data tags 1–3, respectively, were executed without an error. A data transfer however from server 20 to workstation 10 of a data unit 4 responsive to a read command 4 tagged with a data tag 4 did not occur in a timely manner as represented by the dashed arrow, which results in an issuance of a reset error from workstation 10 to server 20 whereby workstation 10 and server 20 are reset to an equivalent state that excludes outstanding read command 4. Assuming the reset of workstation 10 and server 20 to the equivalent state was successful whereby outstanding read command 4 has been eradicated, sequential data transfers from server 20 to workstation 10 of data units 5–8 responsive to read commands 5–8, respectively, tagged with data tags 1–4, respectively, can be executed without a data error. However, if the reset of workstation 10 and server 20 to the equivalent state was unsuccessful whereby server 20 maintains a processing of outstanding read command 4 after an issuance of read command 8 having the same data tag 4, then a data error will occur if server 20 transfers data unit 4, which is unresponsive to read command 8, to workstation 10 as represented by the dashed arrow prior to a transfer of data unit 8, which is responsive to read command 8, to workstation 10. The data error in this case involves an incorrect correspondence of data unit 4 to read command 8 by workstation 10.
The computer industry is therefore continually striving to improve upon data tag methods with the goal of avoiding the occurrence of aliased tokens associated with data errors resulting from an incorrect correspondence of a data unit to an issued data transfer command (e.g., a read command or a write command).